REMARKS 

1. Applicants have amended the first paragraph of this application in accordance 
with the suggestions of the Examiner on page 3 of the Office Action dated 02/28/2006, to fulfill 
the requirements of 35 U.S.C. 120 and 37 C.F.R. 1.78. 

2. Applicants have revised the claims in accordance with the suggestions of the 
Examiner. Applicants have also revised the claims to make the claims definite and to eliminate 
inconsistencies that applicants' attorney noted in the claims in preparing this amendment. As 
now written, the claims are believed to be definite. 

3. The Examiner has cited as a separate reference, against a number of the claims 
including claims 6, 7, 8, 9, 10-12, 24, 25, 39 and 40-42, the Altman et al. pending application 
US2003/8120526 filed on October 16, 2002. Altman has a filing date of 10/16/2002. This is 
after applicants' filing date. 

Altman filed provisional application 60/329,281 on October 16, 2001 in the 
USPTO. Applicants are enclosing a copy of the Altman provisional application. As the 
Examiner will note, the Altman provisional application does not provide a sufficient number of 
drawings or a sufficient specification to support the Altman non-provisional application. For 
example, there are at least ten (10) figures showing circuit diagrams and flow charts in the 
Altman non-provisional application. There are no circuit diagrams or flow charts in the Altman 
provisional application. 

37 CFR 1 .53(c) reads as follows: 

''Application filing requirements - Provisional application. 
The filing date of a provisional application is the date on which a 
specification as prescribed by the first paragraph of 35 U.S.C. 112, and 



133624.1 



14 



U.S. Serial No. 10/027,477 
Attorney-Docket No. CFARE-59170 



any drawing required by §1.8 J (a) are filed in the Patent and Trademark 
Office. No amendment, other than to make the provisional application 
comply with the patent statute and all applicable regulations, may be 
made to the provisional application after the filing date of the provisional 
application. " 

In accordance with the provisions of 37 CFR 1.53(c), the Altman provisional application has no 
effect in establishing a filing date of the Altman non-provisional application since Altman filed 
the non-provisional application after 12/2/01 , the filing date of this application. Because of this, 
the Examiner should withdraw the Altman non-provisional patent application as a prior art 
reference and should allow claims 6, 7, 8, 9, 10-12, 24, 25 and 40-42 over the other references 
cited by the Examiner. 

4. Claims 26-29, 3 1 , 33, 34 and 36 have been rejected under 35 U.S.C. 103(a) as 
being unpatentable over Iyengar patent 6,360,205. Claims 26-29, 31, 33, 34 and 36 are 
allowable over Iyengar for the following reasons, 
a. Claim 26 

In claim 26, applicants recite that the legacy transactions are performed 
simultaneously with the individual transactions and that the legacy transactions and the 
individual transactions are provided simultaneously. Applicants also recite that the legacy 
transactions and the individual transactions are displayed simultaneously on different portions of 
a display screen. Iyengar does not disclose this. Contrary to the position of the Examiner, 
Iyengar does not disclose, in (a) column 7, lines 48-60, (b) column 9, lines 40-43, (c) column 11, 
lines 30-34 and (d) column 16, lines 4-7, the steps of providing prices for the transactions at a 
processing station from a plurality of first sources at published prices for the transactions, and 
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providing for the transmission of the prices discounted from the established prices from the first 
sources to the processing station. Iyengar also doesn't disclose in column 16, lines 4-17 that the 
searches for the published and the discounted fares are performed simultaneously. There is also 
no disclosure by Iyengar in column 1 1, lines 30-35 that the published prices and the discounted 
prices are displayed simultaneously on a display screen. Because of the failure of Iyengar to 
disclose the features discussed above, claim 26 is allowable over Iyengar. 

b. Claim 27 

Claim 27 is dependent from allowable claim 26. Furthermore, Iyengar 
does not disclose, in (a) column 1 5 lines 56-61, (b) column 7, lines 49-61 (c) column 8, lines 6-9, 
(d) column 1 1, lines 30-55, (e) column 16, lines 4-17 and (£) column 3, lines 10-14, that the 
published prices for the transactions are provided in a first protocol, that the discounted prices for 
the transactions and the prices from other sources are provided in a second protocol and the first 
and second protocols are made compatible and that the published prices and the discounted 
prices in the compatible protocol are displayed simultaneously on the display server. 

c. Claim 28 

Claim 28 is dependent from allowable claim 26. Iyengar 
additionally does not disclose, in (a) column 6, lines 60-65, (b) column 7 3 lines 49-61, (c) 
column 8, lines 6-9, (d) column 16, lines 4-17 and (e) column 3, lines 10-14, the steps of 
providing prices for the transactions at the processing station from at least one second 
source offering published prices for the second source, the second source being different 
from the first source, providing for the transmission of the published prices from the at 
least one second source to the processing station and displaying the published prices from 
the at least one second source on the display server simultaneously with the display of the 
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published and discounted prices from the first source and the other sources and from the 
at least one second source in the display server simultaneously with the display of the 
published and discounted prices from the first source and the other sources. Because of 
this, claim 28 is allowable over Iyengar. 

d. Claim 29 

Claim 29 is dependent from allowable claim 28. Claim 29 is also 
allowable over Iyengar because of the recitations in claim 29. For example, Iyengar does 
not disclose that the published prices from the at least one second source is provided with 
a protocol different from the first and second protocols, that the fares from the first and 
second sources are searched simultaneously and that the fares are displayed 
simultaneously. 

e. Claim 3 1 

In analyzing claim 31, the Examiner has referred to Altman. 
Applicants are analyzing the Examiner's interpretation of the claim on the basis that the 
Examiner intended to refer to Iyengar. 

The Examiner has not cited portions of Iyengar against claim 31. 
However, Examiner does not disclose any of the steps recited in claim 31. 

f. Claim 32 

Claim 32 is dependent from allowable claim 31. furthermore, the 
Examiner has admitted that Iyengar does not disclose the steps of providing a printer at 
the legacy server and printing, in the printer at the legacy server, a ticket providing for the 
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performance of the selected one of the legacy and individual transactions as the particular 
transaction. 

The Examiner has indicated in column 14, lines 5-11, that a 
confirmation is sent to the legacy server and that the legacy system mails the customer a 
ticket. Therefore, according to the Examiner, it would have been obvious to one of 
ordinary skill in the art at the time of the invention to modify the invention of Iyengar to 
include printing the ticket at the legacy server so that the ticket is automatic. However, 
Iyengar does not disclose that the legacy server prints the ticket and furthermore that the 
legacy server prints the ticket at the time of the selection of the legacy. 

g. Applicants have added claim 43 in this amendment as dependent 
from allowable claim 42. Claim 43 is allowable over Iyengar because Iyengar does not 
disclose the step of simultaneously printing in the printer at the legacy server, the cost of 
the ticket providing for the selected one of the legacy and individual transactions as the 
particular transaction. 

h. Claim 33 

Claim 33 is dependent from allowable claim 31. 

i. Claim 34 

Claim 34 is allowable over Iyengar because it is dependent from 
allowable claim 31 . Furthermore, column 6, lines 13-20 in Iyengar does not disclose that 
the indications of the legacy transactions are provided to the database at the processing 
station through a wide area network. 
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j. Claim 35 

The Examiner has apparently cited the combination of Iyengar and 
Gerra against claim 35. Claim 35 is dependent from claim 33 and is accordingly 
allowable over the combination of Iyengar and Gerra for the same reasons as claim 33. 
This has been discussed previously in these remarks, 
k. Claim 36 

Claim 36 is dependent from allowable claim 35. Claim 36 is also 
allowable over Iyengar for the same reasons as claim 34. 

Claim 36 has been rejected under 35 U.S.C. 109(a) as being 
unpatentable over Iyengar in view of Gerra. Claim 36 is allowable over the combination 
of references for certain important reasons. 

For example, the Examiner has admitted that Iyengar does not 
disclose prices on the first and second portions of the display screen. The Examiner has 
cited Gerra in column 2, lines 62-67 and Gerra , column 2, lines 30-40. Column 2, lines 
20-30 in Gerra is in the Background of the invention. Gerra indicates a need rather than 
an accomplishment. Column 2 5 lines 62-67 in Gerra is in the Summary of the Invention. 
It does not indicate that the published prices from the first sources and the published 
prices from the at least one second source are in incompatible formats and these 
published prices are displayed in a compatible format. For the reasons specified above, 
claim 36 is allowable over the combination of Iyengar and Gerra. 

5. The Examiner has cited other references than Iyengar against a number of 
the claims including; 
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a. Claim 37 

Claim 37 has been rejected under 35 U.S.C. (4) as being 
unpatentable over Iyengar in view of Gardiner patent application 052002/017034. Since 
claim 37 is dependent from allowable claim 34, claim 37 is allowable over the prior art 
for the same reasons as claim 34. 

The Examiner has admitted that Iyengar does not disclose the steps 
of providing an accounting application at the legacy server and operating the accounting 
application at the legacy server to provide an accounting record of the selected one of the 
legacy and the individual transactions as the particular transaction and to provide an 
accounting record of the price of the selected one of the transactions. Gardiner also does 
not disclose this information in paragraphs 0007, 0039, 0045 and 0053. Because of this, 
claim 37 is allowable over the combination of Iyengar and Gardiner. 

b. Claim 38 

Claim 38 has been rejected under 35 U.S.C. 103(a) as being 
unpatentable over Chen pending application US 2002/0152100. Actually, claim 38 has 
been rejected over a combination of Chen and Altman. (See the last two(2) sentences on 
page 2 1 of the Office Action concerning Altman.) Since Altman is not a good prior art 
reference for the reasons discussed above, Chen 38 is allowable over Chen when only 
Chen is used as a prior art reference. 

Furthermore, contrary to the position of the Examiner, Chen does 
not disclose in paragraphs 0028 and 0036 the steps of providing legacy transactions and 
individual transactions and providing a local area network and a printer at the processing 
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station. Chen also does not disclose in paragraphs 0061-0065 the steps of providing at 
the processing station a database for storing volatile information including a selected one 
of the legacy transactions and the individual transactions, and the price of the selected 
one of the legacy transactions and the individual transactions, as the particular 
transaction. There is also no disclosure in Chen of the step of providing for the passage 
through the internet to the printer of the selected one of the legacy transactions and the 
individual transactions as the particular transaction and the cost of the selected one of the 
legacy transactions and the individual transactions. There is also no disclosure in 
paragraph 0032 of Chen of the step of printing at the printer the selected one of the 
legacy transactions and the individual transaction. According to the Examiner, Chen has 
admitted that Chen does not disclose the printing of the selected transaction. 

For the reasons discussed above, claim 38 is allowable over Chen and the 
combination of Chen and Pitman. 

c. Claim 39 

Since claim 39 is dependent from allowable claim 38, it is allowable 
over Chen, and the combination of Chen and Altman, for the same reasons as claim 38. 
Altman, in paragraphs 35 and 50-59, and Gerra additionally do not disclose that the 
legacy transactions, and the price of the legacy transactions, are transmitted to the 
processing station through a wide area network and that the individual transactions and 
the price of the individual transactions are transmitted to the processing station through 
the internet. Altman is also not a proper reference for the reasons discussed above. 
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d. Claims 40-42 

Claims 40-42 have been rejected under 33 U.S.C. 103(a) as being 
unpatentable over Chen in view of Gerra in view of Altman. Claims 40-42 are allowable 
over the combination of Chen and Gerra since Altman is not a proper reference for the 
reasons discussed above. 

e. Claim 40 

Gerra does not disclose in (a) column 7, lines 1-25 and column 8, 
lines 4-7 that the legacy transactions are provided in a first protocol, the individual 
transactions are provided in a second protocol different from the first protocol and the 
first and second protocols are made compatible at the processing station. Paragraph 0059 
in Altman, additionally provides a general discussion that does not disclose what is 
specifically recited in claim 40. Furthermore, Altman is not a proper reference for the 
reasons discussed above. 

f. Claim 41 

Claim 41 is dependent from allowable claim 40. 

g. Claim 42 

Claim 42 is allowable over the references for the same reasons as 
claim 40 because it is dependent from allowable claim 40. 

6. A number of the claims are allowable over the references because Altman 
is not a proper reference. The other claims are allowable over the cited references 
because they recite features not disclosed in the cited references. 
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Reconsideration and allowance of the application are respectfully requested. 



Howard Hughes Center 
6060 Center Drive, Tenth Floor 
Los Angeles, CA 90045 
Telephone: (310) 824-5555 
Facsimile: (310) 824-9696 
Customer No. 24201 
JKF:ftd 

Enclosure: (Copy of the Altman provisional application 60/329,281 filed 10/16/2001) 
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Graphical Travel Wizard 

Graphical Travel Wizard j 

Graphical City Selection for Online Reservation Booking ] \ 
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Enforcement of Travel Policy during Booking 5 
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Graphical City Selection for Online Reservation Booking 

5 Selection of cities from a map used as input into a GDS (aka, online reservation 
g system) for the retrieval of actual Flight Schedules/Fares, Hotel Availability/Rates, 
w Car Availability/Rates, Reserving, and Booking a trip. This allows the system to 

accept the travel cities, and uses that data to run a real-time query against the GDS to 
(U retrieve Air/Hotel/Car availability, and once the user has made a selection, a 
0} reservation will be created. 

J* Unique features: 

0 Traveler selects cities - not airports - the Outtask system looks up the 

0 correct airport or region code to supply to the GDS. This makes travel 

J* planning easier, eliminates errors, and allows Outtask to extend the 

jjj availability search to include all airports in a region. 

h 0 Smart defaulting of personal and corporate preferred airports. This allows 

a company to specify that a particular HOME airport always be included in 
the search - in a multi-airport city this can force unpopular but cost 
effective departure airports to be included. 

o Smart defaulting of personal and corporate preferred airlines/hotels/cars. 
Tlus allows a company to specify that a particular carrier will always be 
included in the search - this feature is particularly useful for cornpanies 
that have volume contracts with a particular carrier. Combined with our 
preferred carrier rules enforcement it will allow a company to enforce 
strict control over employee travel on non-preferred carriers. 
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Incorporation of Government PerDiem Data into Travel Rules 
Enforcement 

This is provided under the rules policy enforcement in die Outtask Travel system. It 
will either warn the user of an infraction, or require approval before the booking can 
proceed This feature works as follows for hotel rates: 

• US Government per-diem rates are electronically loaded into Outtask 

• PerDiem users are informed when they attempt to reserve a hotel that exceeds 
the PerDiem rate for that locality 

■ When the PerDiem policy is in effect one of the following happen when a 
hotel rate exceeds the amount for that location. 

o Warning-Tlie user will be required to enter a reason for the out of policy 
reservation, the user's manager will be informed, and the booking will 
proceed. 

o Approval Required - The user will be required to enter a reason for the 
out of policy reservation, the reservation will be cancelled unless the user's 
CI manager approves the request 

0 

W 

W 




3 




4 



CI 
0 

w 
w 
<a 
w 
o 

* 

K 
O 
H 

a 

H 




Enforcement of Travel Policy during Booking 

Designation and enforcement of corporate travel policy when the user is in the 
booking process - as the user Selects a Flight, Hotel, or Car that is disallowed under 
company policy 1) the user is notified, and 2) it will not be allowed to go to ticketing 
until approval. In easting systems, travel rules enforcement occurs after the 
employee has performed the booking by the Travel agent - Outtask's system is much 
unproved over these systems- it alerts the employee at the time of the rule inflection 
and presents acceptable alternatives to avert out of policy travel 
Unique features: 
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o On a per rule basis, the employee' s manager can be notified and the 
ticketing allowed to continue, or ticketing will be blocked until the 
manager approves the trip itinerary. 

o When a user chooses a flight/car/hote! that is more expensive than a travel 
rule allows, a message will be generated for manager notification/approval 
that will include the lower cost options that the traveler decided not to 
take, and a message from the employee explaining the reason. This 
information will be included in both an email message to the manager, and 
the system log. 

o Green / Yellow / Red coding of Air Fare, Car Rates and Hotel Rates 
indicating - Within Company Policy, Allowable but Requires Manager 
Notification, and Out of company policy - will require approval prior to 
ticketing. 

o All rules arc computed based on the NET ticket price; this includes both 
the Front-end and Backend ticket prices. 

o Configurable rules for Air/Hotel/Car in the following form: 

■ Approval/Notification if rate is $X above the best fare found 

■ Approval/Notification if rate exceeds $X maximum allowable by 
company policy 

■ Approval/Notification for airtare/car/hotel on non-preferred carrier 

■ Approval/Notification for airfare/rate on non-preferred carrier 
where preferred carrier is within $X of the non-preferred fere 
Approval/notification on a non-preferred carrier between 2 cities 
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Incorporation of Carrier Direct fares with Data from GDS/CRS 

This feature of the Outiask online travel system allows outtask to offer customers 
fares from both a GDS (Global Distribution System) and Internet Direct fares. 
Merged into a single user interface for fare selection. 

Key aspects of this integration 

• Combining GDS data with Internet direct fares provides user a single place to 
comparison shop the entire internet 

■ Internet Direct fares are filtered based on customer travel policy - this allows 
only showing internet direct fares that arc a substantial savings 

■ User is notified as to the policy compliance of any fare at the time of purchase 
regardless of its source (GDS or Internet). 

■ The system performs buy tracking to capture internet bookings and integrate 
this data back into the Travel Reporting system. 

Key Technical Aspects 

■ Combined presentation of fares from multiple providers 
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• Filtering out Internet direct fares based on company policy 

• Capturing the BUY event so that reporting can take place. 

■ User is asked to verify the itinerary that the BUY tracking detects as being 
correct 
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In Browser Support from Travel Agent In Online Booking 

This feature allows the user of the Outtask Online booking system to contact a travel 
agent or customer support engineer for help with Online booking. Using this system, 
the user can contact a Travel Agent or CSR in the following ways: 
■ Voice Over IP Phone conversation 

* Shared Browsing session 

B The Vote over IP support aHows a usct^ 

agent for immediate support during the booking process. This allows a 
Traveler to make reservations w/o requiring an agent to be involved, but 
provides the utility of an immediately available. If the traveler has progressed 
to the point of having a reservation in the system the travel agent is able to 
retrieve the reservation for review or modification while the customer is 
online. 

fll ' S ^ cd ^^"^ support aiJows a user to enter an interactive chat dialog with 

0 a CSR whae Ac user is in the process of booking. This facility allows a CSR 

y to push scre<ms to the user to assist m the booldng process. 

g Integration of Multiple Travel Data sources into an 
, Expense Management system 

o 

« Outtask Expense Management system, Violet, integrates Credit Card data feeds 

g of charge information into the Expense Report creation process. 

J* These features of the system do (he following: 

« Incorporate Post Booking information into the Expense Management System 

combined with other data sources to form an expense record. 
■ *^etheTUceipro^eIe(^<^ 

remitting paper receipts to support paperless expense management 

• Allow the wireless entry of travelers expenses into staging area for expense • 
reporting 

Post Booking Information 

2iu^, 0fPO ^^ Won3 ^ OD ut0 *• Ex P ensc Management System 
allows all data that presented in a Travelers Itinerary to be tocorporatedinto an 
«P«s< i report The key technology issue is the ability to tie a data record to the 
appropriate user. Once competed, the post booking data is used to complete an 
expense record. This record includes the following information: Travel Dates, vendor 
amount. der«W< carrier, taxes, and record specific information such as ticket 
number. Other available data sources MAY be correlated to this record to add to the 
data record. For instance, a Post Ticketing rental car expense record will contain 
travel days, and vendor information, but not final cost This system will correlate the 
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post ticketing record with a credit card charge record, and complete the rental car 
expense record 



Electronic Receipt Management - Paper less expense reporting 

This feature alleviates the user from having to turn in receipts for items that can be 
captured and tracked electronically. This feature combined with user authentication at 
submission time to verify the identity of the user submitting the expense will enable 
paper-less expense report management The "eiectonic" record of the expense item is 
maintained in an un-aiterable form associated with the expense. When the company 
needs to review the receipt, it is accessed via a web browser. 

Wireless Device Expense Collection 

A user can enter a record of an expense from a Wireless device. This record will be 
available for use the next time a user completes an expense report The following 
information is transmitted; Expense Type, Amount, Date, Project, and a comment 
Once stored as an expense record the user simply clicks the expense into the expense 
<fi report This feature should be distinguished from that of filling out an expense report 

O using a wireless device, and submitting it We believe that this is a much more user 

y friendly approach to capturing the expense at the time it occurs, and then 

JJJ incorporating it into an expense report when a user has access to a computer. 

SU 

g Audit system for EFT payments from a Expense 
Management System 

0 In the T&E system we manage electronic funds Uznsfcr payments for many of our 

p customers. We process millions of dollars a day in funds payments. The sheer 

O v " oIume ofthc transfers is so large that there is no economical way to manually audit 

H» to transfers to see whether any defects in the system led to problems with the files. 

Malfunctions in the payment subsystem are costly as once the payment is made and 
the money transferred it is difficult to undo any errors. Additionally there is no 
economical way to manually detect whether there is anything out of the ordinary with 
the files of one of our customers that would indicate that they made errors when 
releasing reports or if someone managed to find a way within the system to get a large 
report approved that should not have been. 

With tius invention we analyze the transfer amounts themselves statistically to see 
whether day fall outside the norms of the transfers for that company. We also 
anaJyze the individual expense reports that are being paid to sec if the report was not 
approved when typically that traveler's reports require approval. We check the total 
amount paid to each traveler to sec if any traveler's reimbursement total is above a 
ftreshold. We also check the age of tter^ 

that it was possibly already paid. This way we can investigate to prevent accidental 
double-payment due to system malfunction. 

The audit system generates reports in HTML format daily. These reports are sent to 
appropriate administrators for review and can optionally be sent to Outtask customers. 
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The parameters for the audit system can be configured on a company by company 

basis. 



w 

W 
•0 

■ 

0 

c 



The audit report is generated after (he EFT files are generated and before they are 
transmitted (the transmission is manual for security reasons). Our staff has the ability 
to act on any issues raised by the audit report prior to sending the files. This audit 
system has allowed us to be proactive and contact customers with suspected issues 
before their adrainistrators have discovered them. 

The architecture of the auditing system has an extensible architecture to support 
customer specific business process audit rules. The business rule has to be express- 
able in terms of on data elements contained in the EFT, previous reports from mat 
company, or the previous transfers from that company. 

Audit Example: 

10/02/2001: Results of running ludtt procedures: 



142123.29 

Total batch payaent is higher than average 



ft* Ca,h 
52507 



10848.14 

total payments for thtl employ** «xca*da 10OOO 



Caan 
032033 

20330U2fthc473« 
599.48 

Report vaa automatically approved 
Caah 
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ToUl batch payaeot is higher than average 



Cash 
34094 

4O<M0622dvl0O48 
117.3 

Raport waj automatically epp roved 



CC 

1020J4 

2034Q927kvl3439 
469.78 

Report we * «utoQatlcally approved 



Cash 



6995.06 

Total batch payaeat i« higher than average 



C«3h 

241824.57 

Total batch payment U higher than iv«rage 



Cash 
4425.26 

Total batch payment la higher than average 



Cash 



5439.99 

Total batch payment la higher than average 



W02/2001: VfnPayer did not create any payments for following customers 



UUK060P 213 



1$3 

fT? 

KPCfSfiOl bio 



J? 



prmotc-bilmiig- 



■PREKOTC-BILLING- 



1:21:3119a) 



>l:07;30(3i) 



CC «01:18:4<(2s) j 




immmi VinPtyer created payment files for following customers: 



Bank: MSA (OS) 

CC: HASTE* CARD 

RUO : CASH-PIOrOTS-BILLIHG 



ACH fl«i 10020118. KBA 



Batchcs/Octdli 
Debits 

Crtdita 



1/S? 
0.00 

142421.29 



0/0 



Pxeaote: 



0/0 



Billing: 
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0/0 



CC: 



Total: 

1/97 
0.00 

142423.29 



Bank: B00(0S1 

Run : CASH-PREKOTE-BILLWC 



AC8 1002012 6 -BOO 

O Batchea/0et*lj 
Credit* 



w 



0.00 
2053. ei 



0 

O o/o 8iui ** 
C} 



0/0 



2/7 

o.oo 

2053.81 



Business Workflow for Requests and Approvals 

The invention is an object-oriented workflow framework designed to unify user 
requests across a heterogeneous environment The end users see a single "Request 
Queue" tracking requests they have made, and a single "Approval" queue for requests 
from others that they must act upon even though the physical requests may reside on 
different systems. The intellectual property here is an object-oriented framework 
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which is data independent that manages each of the requests through several stages, 
enforcing rules or other business logic. 

The idea of the single request and approval queue is not new to the Outtask system. 
From the perspective of the end user this functionality has been in the product since 
our initial release back in late 1999. However that initial system was built specifically 
to handle manually inserted travel requests (not requests taken from a CRS feed), and 
while we had hoped that it would be easily extended to handle requests from other 
products it turned out not to be so. We began a redesign of the system from the 
ground up in June of 2000. Over the next several months we deployed a partial 
instance of the invention that could handle HR requests in addition to the manually- 
inserted travel requests, but now we are preparing to roll out the final version which 
has been updated to read data from a CRS system and has automatic rules 
enforcement built into it These last two pieces are key intellectual property for us as 
they represent how we have been able to integrate multiple CRS feeds into the 
Outtask system. 

This feature provides an object-oriented framework for workflow that exposed a 
<M single API for creating, promoting, rejecting, and fulfilling any request that a user 
W could make. The framework is data independent so that the physical requests can lie 
Jjj in different systems without any changes being made to the framework. We have also 
added object-oriented rules enforcement logic to this framework. The nature of this 
framework is such that we can add or integrate other products into the Outtask 
0 framework quickly and easily. All we need to do is build the data access layer and 
M ^ cn our 0-0 framework takes over from there. Our developers can manipulate any 
„ type of request, be it a HR Leave request, a Travel request, or a request for an order of 

H office supplies with the same high-level code. 

0 

I* The workflow supported by the framework is as follows: 

1 ) Zero or more "preprocessing" steps. Preprocessing steps are those required 
W before the request would need to be approved. 

2 ) or more "approval* steps, where a person (typically a manager) 
approves the request 

3) Zero or more "processing" steps. Processing steps are those required after 
approval but before the request can be fulfilled 

4) One or more "fulfillment" steps, where the request is actually fulfilled. 

Additionally a request can be rejected during the preprocessing, approval, and 
processing steps, and can be withdrawn by the requestor any time prior to fulfillment 

Some examples of this workflow: [NB: We have to decide whether the rules 
enforcement is part of preprocessings after writing mis I think it may be but we could 
enforce rules wherever we wanted -Fred]. 

Travel. In the preprocessing steps the traveler goes online or calls a travel 
agent and makes a reservation in the system. The. automated rules system receives the 
reservation from the CRS and determines whether this specific request requires 
approval (and if so by whom) or if the request meets policy guidelines. If the request 
requires approval it is routed to one or more people or alternatively one or more 
queues where groups of people can approve the request before it proceeds to 
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processing and fulfillment If the request does not require approval it proceeds 
straight to processing and fulfillment. During the processing phase the agent confirms 
the reservation and the credit card is charged. If the credit card charge is accepted by 
the credit card company the request is fulfilled by the issuing of the ticket 

Human Resources Leave Request After the request has been entered, there is 
no preprocessing required. The automated rules system examines the request and 
company policy to determine wither this specific request requires approval (and if so 
by whom). If the request is approved, or if the request did not require approval, then 
the request proceeds to fulfillment, where the employee's leave bank is decremented 
by the amount of the request 

In either case, had the approver rejected the request it would have been sent 
back to the requestor who would have had the opportunity to comment further on the 
request and resubmit it, or withdraw the request In the travel case, the travel agent 
could reject the request during processing if the reservation made during the 
preprocessing phase had expired and no equivalent reservation could be made. The 
agent could also have rejected during preprocessing if no reservation could be made 
ffl that met the traveler's criteria and company policies. 

o 

g Booking Management Process 

j, 4 This system employs a set of configurable rules/business processes that allow agents 

a to segregate travel requests booked through the Outtask Travel System based on 

g,i priority/importance on a set of factors. Based on the segregation, special attention can 

O be paid to certain types of requests. The a sample of the rules used to classify 

M reservations for special handling include the following configurable factors: 

0 ■ Travelers marked as VIP by the travel agency (e.g. CEO/COO, tvL mgr. etc): 

Ngh priority handling. Routed to special queues in the GDS for personal care 

• Trips with expensive tickets that meet certain reqmts (e.g. Saturday night 
stay): high priority handling. Tickets like this can be ideal candidates for 
agents to seek fee waiver requests. If I have a $2000 ticket Tm buying 4 days 
before I leave, and it has a Saturday night stay, it might be worthwhile for the 
agent to get me a 3-week advance waiver, dropping the ticket to $800 + (let's 
say) a $400 fee charged by the agent Saves the traveler's company $800, 
makes us $400. 

• Tickets for travel in next N days: agents are much more aggressive on getting 
these issued, lets say. . 

• Travelers taking trips on airlines on which they have status: high priority 
handling If a United 100,000 traveler has a trip on United, that trip is queued 
for priority handling regarding upgrades/waivers/whatcver. 

• Fare expiration rules: trips can be evaluated for how soon until the fare 
expires, and routed/re-routed based on that information. In other words, a fare 
good for another 10 days can go on a low priority queue. If it's still sitting 
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